Software applications, e.g., a social networking application, can be implemented as a mobile application (“mobile app”) that can be installed on client devices, or can be implemented as a web-based application that can be accessed by end-users using a web-browser or web-browser-like application from their client devices. A software application (“application” or “app”), regardless of whether it is implemented as a mobile app or a web-based application, can crash, e.g., fail, due to an error in the source code of the application or other reasons. Typically, a crash report detailing the crash is generated when the application crashes, e.g., on a client device. The crash report is then forwarded from the client device to an application provider where typically a person in charge of processing the incoming crash reports reviews the crash report to identify an entity, e.g., a programmer, to whom the crash report is to be assigned for resolving the error. The programmer then analyzes the crash report, identifies the cause of the error, and resolves the error, e.g., by revising the source code.
This process for evaluating the crash reports and resolving the errors can be inefficient, tedious, inaccurate and cause a great deal of delay in resolving the errors. For example, having a human user review and forward the crash report to the programmer can be overwhelming or even impossible if a large number of crash reports is received, which is a possibility considering that the social networking mobile app is typically installed on millions of client devices. Further, sending the large number of crash reports to the programmer can be “spam” like, especially if a group of the crash reports are for crashes that occurred due to the same error, and the programmer may inadvertently miss reviewing one or more crash reports. Furthermore, identifying a programmer to whom a particular crash report is to be assigned can consume significant time for the human user, which can cause a delay in resolution of the error.